Distributed process control systems, like those used in chemical, petroleum and/or other processes, systems, and/or process plants typically include one or more process controllers communicatively coupled to one or more field devices via any of a variety of analog, digital and/or combined analog/digital buses. In such systems and/or processes, field devices including, for example, valves, valve positioners, switches and/or transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and perform process control and/or management functions such as opening or closing valves, measuring process parameters, etc. Smart field devices, such as field devices conforming to any of the Fieldbus protocols may also perform control calculations, alarming functions, and/or other variety of control and/or monitoring functions that may be implemented within and/or by the controller. The process controllers, which may also be located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices. Based on, for example, the received signals, the process controllers execute a controller application to realize any of a variety control modules, routines and/or software threads to make process control decisions, generate control signals, and/or coordinate with other control modules and/or function blocks being performed by field devices, such as HART and Fieldbus field devices. The control modules in the controller(s) send the control signals over the communication lines to the field devices to control the operation of the process plant.
Information from the field devices and/or the controller is usually made available over a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers, data historians, report generators, centralized databases, etc. Such devices are typically located in control rooms and/or other locations remotely situated relative to the harsher plant environment. These hardware devices, for example, run applications that enable an operator to perform any of a variety of functions with respect to the process(es) of a process plant, such as changing settings of the process control routine(s), modifying the operation of the control modules within the process controllers and/or the field devices, viewing the current state of the process(es), viewing alarms generated by field devices and/or controllers, simulating the operation of the process(es) for the purpose of training personnel and/or testing the process control software, keeping and/or updating a configuration database, etc.
As an example, the DeltaV™ control system sold by Fisher-Rosemount Systems, Inc. an Emerson Process Management company supports multiple applications stored within and/or executed by different devices located at potentially diverse locations within a process plant. A configuration application, which resides in and/or is executed by one or more operator workstations, enables users to create and/or change process control modules, and/or download process control modules via a data highway or communication network to dedicated distributed controllers. Typically, these control modules are made up of communicatively coupled and/or interconnected function blocks that perform functions within the control scheme based on received inputs and/or that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration engineer and/or operator to create and/or change operator interfaces which are used, for example, by a viewing application to display data for an operator and/or to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, field devices, stores and/or executes a controller application that runs the control modules assigned to implement actual process control functionality. The viewing applications, which may be run on, for example, one or more operator workstations, receive data from the controller application via the data highway, and/or display such data for process control system engineers, operators, or users using user interfaces that may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and/or executed by a data historian device that collects and/or stores some or all of the data provided across the data highway. A configuration database application may run in yet another computer communicatively coupled to the data highway to store the current process control routine configuration(s) and/or data associated therewith. Alternatively, configuration application(s), viewing application(s), data historian application(s), configuration database(s) and/or configuration database application(s) may be located in and/or executed by any number of workstations including, for example, a single workstation.
Example configuration applications include a library of template objects, such as function-block template objects and/or control-module template objects that are used to configure and/or construct a control strategy for a process plant. Example template objects have associated default properties, settings and/or methods such that a process engineer and/or operator can, via a configuration screen, select and/or utilize one or more template objects to develop a control module. During the process of selecting template objects via the configuration screen, the engineer interconnects the inputs and/or outputs of these objects and/or may change their parameters, names, tags and other properties to create a specific control module for a specific use in the process plant. After creating one or more such control modules, the engineer can then instantiate the control modules and download them to the appropriate controller(s) and/or field device(s) for execution during operation of the process plant.
The engineer can also create one or more displays for operators, maintenance personnel, etc. of the process plant by selecting and/or building display objects using, for example, a display creation application. These displays are typically implemented on a system-wide basis via one or more of the workstations, and provide preconfigured displays to the operator or maintenance persons regarding the operating state(s) of the control system(s) and/or the devices within the plant. Example displays take the form of alarming displays that receive and/or display alarms generated by controllers or devices within the process plant, control displays that indicate the operating state(s) of the controller(s) and other device(s) within the process plant, maintenance displays that indicate the functional state of the device(s) and/or equipment within the process plant, etc. In some examples, displays are created through the use of objects that have a graphic associated with a physical and/or logical element and that is communicatively coupled to the physical and/or logical element to receive data about the physical and/or logical element. The object may, for example, change the graphic on a display screen based on the received data to illustrate that a tank is half full, to illustrate the flow measured by a flow sensor, etc.
Similar to the control configuration application, a display creation application has template graphical display items, such as tanks, valves, sensors, operator control buttons like slide bars, on/off switches, etc. that may be placed on a screen in any desired configuration(s) to create an operator display, maintenance display, etc. When placed onto the screen, individual graphic items may be interconnected on the screen in a manner that provides some information and/or display of the inner-workings of the process plant to different users. To animate the graphic display, the display creator manually ties each of the graphical items to data generated within the process plant, such as data measured by sensors or indicative of valve positions, etc. by specifying an association between the graphic item and the relevant data source(s) within the process plant.
While the control template objects within the control configuration application and the display items within the display creation application are convenient because they can be copied and then used to create many different control modules and graphical displays, there is often a need to create numerous copies and/or instances of the same control module and/or graphical display for different equipment within the process plant. For example, process plants have numerous instances of the same and/or similar equipment that can be controlled and/and monitored using the same basic general control module and/or display. To create these numerous control modules and/or displays, however, a general control module and/or display module is created and this general control and/or display module is then copied for each of the different pieces of equipment for which it is applicable. Of course, after being copied, each of the new control and/or display modules must be manually altered in the configuration application to specify the particular equipment to which it is attached. Further, all of these control and/or display modules must then be instantiated and downloaded to the process control system(s).
The control modules and/or displays items discussed above are not modular in any manner, thus, after being copied, each of the control modules and/or displays need be manually and/or individually altered using the appropriate configuration application(s) and/or interface(s) to specify the equipment within the plant to which they are to be associated. In a process plant having numerous copies of the same type of equipment (e.g., replicated equipment), this process is tedious, time consuming and/or fraught with introduced errors. Moreover, once programmed, these different control modules and/or displays are not aware of each other (i.e., information concerning the contents in one display is not available to other displays). Therefore, to make a change to already created control modules, the control and/or configuration engineer must manually make the same and/or similar change(s) to each of the different control modules for the different replicated equipment which, again, is time consuming, tedious and/or fraught with introduced errors. The same problem likewise applies to the graphical views created for the different sets of replicated equipment within the plant. In other words, once a specific control module and/or a specific graphical view is created (individually and/or by being copied from a template object) and then tied to a particular set of equipment within the plant, this control module and/or graphical view exists as a separate entity and/or object within the control system and/or process plant without any automatic awareness of the other control modules and/or graphical displays that are the same and/or similar to it. As a result, changes applicable to one or more control modules and/or graphical displays of a particular type must be made individually to those modules and displays.
Still further, because each control module and display is an individual object, it must be open, in the sense that all of its internal parameters, views, function blocks, and/or other elements must be made available for modification, setting, change and/or viewing by any user. Accordingly, there is no readily available ability to, for example, hide certain elements of these control modules and/or displays, such as proprietary software and methods, alarming activities, etc. from a user of the control modules and/or displays.